home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc874.txt < prev    next >
Text File  |  1994-08-01  |  36KB  |  874 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6. ---------
  7.  
  8.  
  9.      < INC-PROJECT, MAP-CRITIQUE.NLS.10, >, 12-Aug-83 11:46 AMW ;;;;
  10.      
  11.  
  12.  
  13.  
  14.  
  15.      RFC 874                                            September 1982
  16.                                                                 M82-50
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.                             A CRITIQUE OF X.25
  25.  
  26.  
  27.  
  28.  
  29.      
  30.      
  31.  
  32.      
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.                               M.A. PADLIPSKY
  47.                            THE MITRE CORPORATION
  48.                           Bedford, Massachusetts
  49.      
  50.  
  51.  
  52.  
  53.  
  54.                                  ABSTRACT
  55.      
  56.  
  57.      
  58.  
  59.           The widely touted network interface protocol, "X.25", and
  60.      its attendant conceptual framework, the International Standards
  61.      Organization's Reference Model for Open System Interconnection
  62.      (ISORM), are analyzed and found wanting.  The paper is a
  63.      companion piece to M82-48, and M82-51.
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70.  
  71.  
  72.  
  73.  
  74.  
  75.  
  76.  
  77.  
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.                                      i
  108.           
  109.      
  110.      
  111.      
  112.                             A CRITIQUE OF X.25
  113.  
  114.                               M. A. Padlipsky
  115.      
  116.      
  117.      
  118.  
  119.      Introduction
  120.  
  121.           According to some sources, the International Standards
  122.      Organization's (ISO) "Open System Interconnection" (OSI) effort
  123.      has adopted the International Consultative Committee on Telephony
  124.      and Telegraphy (CCITT) developed X.25 protocol(s) as its Levels
  125.      1-3. ("Loose constructionists" of the ISORM would hold that X.25
  126.      is a mechanization of L1-L3 rather than the mechanization, and at
  127.      least one British source holds that "we in the U.K. don't believe
  128.      that ISO have adopted X.25.")  In the U.S. Government arena,
  129.      where the author spends much of his time, the Government
  130.      Accounting Office (GAO) has suggested that the Department of
  131.      Defense (DoD) ought to consider adopting "X.25 networks,"
  132.      apparently in preference to networks based on protocols developed
  133.      by the DoD-sponsored intercomputer networking research community.
  134.      That intercomputer networking research community in turn has,
  135.      with a few recent exceptions, adhered to its commitment to the
  136.      Oral Tradition and not taken up the cudgels against X.25 in the
  137.      open literature, even though X.25 is an object of considerable
  138.      scorn in personal communications.
  139.  
  140.           Although the DoD Protocol Standards Technical Panel has
  141.      begun to evolve a "Reference Model" different from ISO's for
  142.      reasons which will be touched on below, there seems to be a need
  143.      to address the deficiencies of X.25 on their own demerits as soon
  144.      as possible. Without pretending to completeness*, this paper will
  145.      attempt to do just that.
  146.  
  147.           The overall intent is to deal with X.25 in the abstract;
  148.      because of who pays the bills, though, a necessary preliminary is
  149.      to at least sketch the broad reasons why the DoD in particular
  150.      should not
  151.  
  152.      ________________
  153.      *  Various versions of X.25 and ISO documentation were employed;
  154.         one incompleteness of note, however, is that no attempt has
  155.         been made to do proper bibliographic citation.  Another
  156.         incompleteness lies in the area of "tutoriality"; that is,
  157.         appropriate prior knowledge is assumed on the part of the
  158.         reader.  (The author apologizes for the omissions but hasn't
  159.         the time or the energy to be overly scholarly.  Reference [3]
  160.         might be of use to the reader who feels slighted.)
  161.  
  162.  
  163.  
  164.  
  165.  
  166.                                      1
  167.      RFC 874                                            September 1982
  168.  
  169.  
  170.      employ intercomputer networks which base their protocol suites on
  171.      the ISO Reference Model (ISORM) with X.25 as Levels 1-3.  (Note
  172.      that this is a different formulation from "use communications
  173.      subnetworks which present an X.25 interface.")  Very briefly, the
  174.      DoD has concerns with "survivability," reliability, security,
  175.      investment in prior art (i.e., its research community has a
  176.      working protocol suite in place on many different operating
  177.      systems), procurability (i.e., ISORM-related protocol suites do
  178.      not as yet fully exist even on paper and the international
  179.      standardization process is acknowledged even by its advocates to
  180.      require several years to arrive at full suite specification, much
  181.      less offer available interoperable implementation), and
  182.      interoperability with a much wider range of systems than are ever
  183.      likely to receive vendor-supplied implementations of ISORM
  184.      protocol suites.  Regardless of which particular concerns are
  185.      considered to dominate, the DoD cannot be expected to await
  186.      events in the ISO arena.  (Particularly striking is the fact that
  187.      DoD representatives are not even permitted under current doctrine
  188.      to present their specific concerns in the area of security in the
  189.      sort of unclassified environment the ISO arena constitutes.)
  190.  
  191.           Some zealous ISORM advocates have suggested that the DoD
  192.      research community suffers from a "Not Invented Here" syndrome
  193.      with respect to ISORM-related protocols, though, so even if the
  194.      various reasons just cited were to prevail, there would still be
  195.      an open issue at some level.  At least one or two zealous members
  196.      of the research community have asserted that the problem is not
  197.      Not Invented Here, but Not Invented Right, so an assessment of
  198.      the apparent keystone of the ISORM suite, X.25, from the
  199.      perspective of whether it's "good art" ought to be appropriate.
  200.      That's what we're up to here.
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.                                      2
  226.      RFC 874                                            September 1982
  227.  
  228.  
  229.      Problems With the Conceptual Model*
  230.  
  231.           There is confusion even amongst its advocates as to the real
  232.      conceptual model of X.25-based ISO networking.  Some draw their
  233.      Reference  Model as two "highrises," others draw "parking
  234.      garages" beside each highrise.  That is, some draw the seven
  235.      ISORM layers in large rectangles (representing Hosts) next to one
  236.      another, showing each layer in communication with its "peer" in
  237.      the other Host/Open System; this implies an "end-to-end" view of
  238.      X.25.  Others draw smaller rectangles between the larger ones,
  239.      with Levels 1-3 having peer relationships from the Host-OS ("Data
  240.      Terminal Equipment") to the Comm Subnet Node ("Data Circuit
  241.      Terminating Equipment"); this implies a "link-by-link" view of
  242.      X.25.  This ambiguity does not engender confidence in the
  243.      architects, but perhaps the real problem is with the spectators.
  244.      Yet it is indisputable that when internetting with X.75, the
  245.      model becomes "hop-by-hop" (and it is likely it's meant to be
  246.      link-by-link even on a single comm subnet).
  247.  
  248.           A major problem with such a model is that the designers have
  249.      chosen to construe it as requiring them to break the "virtual
  250.      circuit" it is supposed to be supporting whenever there is
  251.      difficulty with any one of the links.  Thus, if internetting, and
  252.      on some interpretations even on one's proximate net, rerouting of
  253.      messages will not occur when needed, and all the upper levels of
  254.      protocols will have to expend space-time resources on
  255.      reconstituting their own connections with their counterparts.
  256.      (Note that the success of the reconstitution under DCE failure
  257.      appears to assume a certain flexibility in routing which is not
  258.      guaranteed by the Model.)  This can scarcely be deemed sound
  259.      design practice for an intercomputer networking environment,
  260.      although many have conjectured that it probably makes sense to
  261.      telephonists.
  262.  
  263.      ________________
  264.      *  Note that we are assuming an ISO-oriented model rather than a
  265.         CCITT-oriented one (X.25/X.28/X.29) because the latter appears
  266.         to offer only "remote access" functionality whereas the sort
  267.         of intercomputer networking we are interested in is concerned
  268.         with the full "resource-sharing" functionality the former is
  269.         striving for.  This might be somewhat unfair to X.25, in that
  270.         it is taking the protocol(s) somewhat out of context; however,
  271.         it is what ISO has done before us, and if what we're really
  272.         accomplishing is a demonstration that ISO has erred in so
  273.         doing, so be it.  As a matter of fact, it can also be argued
  274.         that X.25 is itself somewhat unfair--to its users, who are
  275.         expecting real networking and getting only communication; cf.
  276.         Padlipsky, M. A., "The Elements of Networking Style", M81-41,
  277.         The MITRE Corporation, October 1981, for more on the extremely
  278.         important topic of resource sharing vs. remote access.
  279.  
  280.  
  281.  
  282.  
  283.  
  284.                                      3
  285.      RFC 874                                            September 1982
  286.  
  287.  
  288.           Indeed, it appears the virtual circuit metaphor is in some
  289.      sense being taken almost literally (with the emphasis on the
  290.      "circuit" aspect), in that what should be an environment that
  291.      confers the benefits of packet-switching is, at the X.25 level,
  292.      reduced to one with the limitations of circuit-switching.  On the
  293.      other hand, the metaphor is not being taken literally enough in
  294.      some other sense (with the emphasis on the "virtual" aspect), for
  295.      many construe it to imply that the logical connection it
  296.      represents is "only as strong as a wire."  Whether the whole
  297.      problem stems from the desire to "save bits" by not making
  298.      addresses explicitly available on a per-transmission basis is
  299.      conjectural, but if such be the case it is also unfortunate.
  300.  
  301.           (As an aside, it should be noted that there is some evidence
  302.      that bit saving reaches fetish--if not pathological--proportions
  303.      in X.25:  For instance, there does not even appear to be a Packet
  304.      Type field in data packets; rather--as best we can determine--for
  305.      data packets the low order bit of the "P(R)" field, which
  306.      overlaps/stands in the place of the Packet Type is always 0,
  307.      whereas in "real" Packet Type fields it's always 1.  [That may,
  308.      by the way, not even be the way they do it--it's hard to tell ...
  309.      or care.])
  310.  
  311.           There is also confusion even amongst its advocates as to
  312.      what implications, if any, the protocol(s) has (have) for comm
  313.      subnet node to comm subnet node (CSN) processing.  Those who draw
  314.      just two highrises seem to be implying that from their
  315.      perspective the CSN (or "DCE") is invisible.  This might make a
  316.      certain amount of sense if they did not assert that each floor of
  317.      a highrise has a "peer-relationship" with the corresponding floor
  318.      of the other highrise--for to do so implies excessively long
  319.      wires, well beyond the state of the wire-drawing art, when one
  320.      notices that the first floor is the physical level.  (It also
  321.      appears to disallow the existence of concatenated comm subnets
  322.      into an internet, or "catenet," unless the CSN's are all
  323.      identically constituted.  And those who hold that the ISORM
  324.      dictates single protocols at each level will have a hard time
  325.      making an HDLC interface into a Packet Radio Net, in all
  326.      probability.)
  327.  
  328.           Those who, on the other hand, "draw parking garages," seem
  329.      to be dictating that the internal structure of the CSN also
  330.      adhere to X.25 link and physical protocols.  This implies that
  331.      Packet Radio or satellite CSNs, for example, cannot "be X.25."
  332.      Now that might be heartening news to the designers of such comm
  333.      subnets, but it presumably wasn't intended by those who claim
  334.      universality for X.25--or even for the ISO Reference Model.
  335.  
  336.  
  337.  
  338.  
  339.  
  340.  
  341.  
  342.  
  343.                                      4
  344.      RFC 874                                            September 1982
  345.  
  346.  
  347.           Even granting that ambiguities in the conceptual model do
  348.      not constitute prima facie grounds for rejecting the protocol(s),
  349.      it is important to note that they almost assuredly will lead to
  350.      vendor implementations based on differing interpretations that
  351.      will not interoperate properly. And the unambiguous position that
  352.      virtual circuits are broken whenever X.25 says so constitutes a
  353.      flaw at least as grave as any of the ambiguities.
  354.  
  355.           Another, in our view extremely severe, shortcoming of the
  356.      X.25 conceptual model is that it fails to address how programs
  357.      that interpret its protocol(s) are to be integrated into their
  358.      containing operating systems.  (This goes beyond the shortcoming
  359.      of the X.25 specifications in this area, for even the advocates
  360.      of the ISORM--who, by hypothesis at least, have adopted X.25 for
  361.      their Levels 1-3--are reticent on the topic in their literature.)
  362.      Yet, if higher level protocols are to be based on X.25, there
  363.      must be commonality of integration of X.25 modules with operating
  364.      systems at least in certain aspects.  The most important example
  365.      that comes to mind is the necessity for "out-of-band signals" to
  366.      take place.  Yet if there is no awareness of that sort of use
  367.      reflected in the X.25 protocol's specification, implementers need
  368.      not insert X.25 modules into their operating systems in such a
  369.      fashion as to let the higher level protocols function properly
  370.      when/if an X.25 Interrupt packet arrives.
  371.  
  372.           Yet much of the problem with the conceptual model might turn
  373.      out to stem from our own misunderstandings, or the
  374.      misunderstandings of others.  After all, it's not easy to infer a
  375.      philosophy from a specification.  (Nor, when it comes to
  376.      recognizing data packets, is it easy even to infer the
  377.      specification--but it might well say something somewhere on that
  378.      particular point which we simply overlooked in our desire to get
  379.      the spec back on the shelf rapidly.) What other aspects of X.25
  380.      appear to be "bad art"?
  381.  
  382.      "Personality Problems"
  383.  
  384.           When viewed from a functionality perspective, X.25 appears
  385.      to be rather schizophrenic, in the sense that sometimes it
  386.      presents a deceptively end-to-end "personality" (indeed, there
  387.      are many who think it is usable as an integral Host-Host, or
  388.      Transport, and network interface protocol, despite the fact that
  389.      its specification itself--at least in the CCITT "Fascicle"
  390.      version--points out several functional omissions where a
  391.      higher-level protocol is expected--and we have even spoken to one
  392.      or two people who say they actually do -- use it as an end-to-end
  393.      protocol, regardless); sometimes it presents a comm subnet
  394.      network interface personality (which all would agree it must);
  395.      and sometimes (according to some observers) it presents a
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.                                      5
  403.      RFC 874                                            September 1982
  404.  
  405.  
  406.      "Host-Front End Protocol" personality.  Not to push the "bad art"
  407.      methaphor too hard, but this sort of violation of "the Unities"
  408.      is, if demonstrable, grounds for censure not only to literary
  409.      critics but also to those who believe in Layering.  Let's look at
  410.      the evidence for the split-personality claim:
  411.  
  412.           X.25 is not (and should not be) an "end-to-end" protocol in
  413.      the sense of a Transport or Host-to-Host protocol.  Yet it has
  414.      several end-to-end features.  These add to the space-time expense
  415.      of implementation (i.e., consume "core" and CPU cycles) and
  416.      reflect badly on the skill of its designers if one believes in
  417.      the design principles of Layering and Least Mechanism.  (Examples
  418.      of end-to-end mechanisms are cited below, as mechanisms
  419.      superfluous to the network interface role.)  The absence of a
  420.      datagram mode which is both required and "proper" (e.g., not Flow
  421.      Controlled, not Delivery Confirmed, not Non-delivery mechanized)
  422.      may also be taken as evidence that the end-to-end view is very
  423.      strong in X.25.  That is, in ISO Reference Model (ISORM) terms,
  424.      even though X.25 "is" L1-3, it has delusions of L4-ness; in
  425.      ARPANET Reference Model (ARM) terms, even though X.25 could "be"
  426.      L I, it has delusions of L II-ness.*
  427.  
  428.           X.25 is at least meant to specify an interface between a
  429.      Host (or "DTE") and a comm subnet processor (or "DCE"),
  430.      regardless of the ambiguity of the conceptual model about whether
  431.      it constrains the CSNP "on the network side."  (Aside:  that
  432.      ambiguity probably reflects even more badly on certain X.25
  433.      advocates than it does on the designers, for there is a strong
  434.      sense in which "of course it can't" is the only appropriate
  435.      answer to the question of whether it is meant to constrain
  436.      generic CSN processors (CSNP's) in the general case.  Note,
  437.      though, that it might well be meant to constrain specific DCE's;
  438.      that is, it started life as a protocol for PTT's--or Postal,
  439.      Telephone, and Telegraph monopolies--and they are presumably
  440.      entitled to constrain themselves all they want.)  Yet the
  441.      end-to-end features alluded to above are redundant to the
  442.      interfacing role, and, as noted, extraneous features have
  443.      space-time consequences. There are also several features which,
  444.      though not end-to-end, seem superfluous to a "tight" interface
  445.      protocol.  Further, the reluctance of the designers to
  446.      incorporate a proper "datagram" capability in the protocol (what
  447.      they've got doesn't seem to be
  448.  
  449.      ________________
  450.      *  For more on the ARM, see Padlipsky, M. A., "A Perspective on
  451.         the ARPANET Reference Model", M82-47, The MITRE Corporation,
  452.         September 1982; also available in Proc. INFOCOM '83.  (Some
  453.         light may also be cast by the paper on the earlier-mentioned
  454.         topic of Who Invented What.)
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.                                      6
  462.      RFC 874                                            September 1982
  463.  
  464.  
  465.      usable as a "pure"--i.e., uncontrolled at L3 but usable without
  466.      superfluous overheard by L4--datagram, but instead entails
  467.      delivery confirmation traffic like it or not; note that "seem" is
  468.      used advisedly:  as usual, it's not easy to interpret the
  469.      Fascicle) suggests at least that they were confused about what
  470.      higher-level protocols need from interfaces to CSNP's, and at
  471.      worst that there is some merit to the suggestion that, to
  472.      paraphrase Louis Pouzin, "the PTT's are just trying to drum up
  473.      more business for themselves by forcing you to take more service
  474.      than you need."
  475.  
  476.           Examples of mechanisms superfluous to the interface role:
  477.  
  478.            1.  The presence of a DTE-DTE Flow Control mechanism.
  479.  
  480.            2.  The presence of an "interrupt procedure" involving the
  481.                remote DTE.
  482.  
  483.            3.  The presence of "Call user data" as an end-to-end item
  484.                (i.e., as "more" than IP's Protocol field).
  485.  
  486.            4.  The "D bit" (unless construed strictly as a "RFNM" from
  487.                the remote DCE).
  488.  
  489.            5.  The "Q bit" (which we find nearly incomprehensible, but
  490.                which is stated to have meaning of some sort to
  491.                X.29--i.e., to at least violate Layering by having a
  492.                higher-level protocol depend on a lower level
  493.                machanism--and hence can't be strictly a network
  494.                interface mechanism).
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.                                      7
  521.      RFC 874                                            September 1982
  522.  
  523.  
  524.           The final "personality problem" of X.25 is that some of its
  525.      advocates claim it can and should be used as if it were a
  526.      Host-Front End protocol.*  Yet if such use were intended, surely
  527.      its designers would have offered a means of differentiating
  528.      between control information destined for the outboard
  529.      implementation of the relevant protocols and data to be
  530.      transmitted through X.25, but there is no evidence of such
  531.      mechanisms in the protocol.  "Borrowing" a Packet Type id for
  532.      H-FP would be risky, as the spec is subject to arbitrary
  533.      alteration.  Using some fictitious DTE address to indicate the
  534.      proximate DCE is also risky, for the same reason.  Further, using
  535.      "Call user data" to "talk to" the counterpart H-FP module allows
  536.      only 15 octets (plus, presumably, the 6 spare bits in the 16th
  537.      octet) for the conversation, whereas various TCP and IP options
  538.      might require many more octets than that.  Granted that with
  539.      sufficient ingenuity--or even by the simple expedient of
  540.      conveying the entire H-FP as data (i.e., using X.25 only to get
  541.      channels to demultiplex on, and DTE-DCE flow control, with the
  542.      "DCE" actually being an Outboard Processing Environment that gets
  543.      its commands in the data fields of X.25 data packets)--X.25 might
  544.      be used to "get at" outboard protocol interpreters, but its
  545.      failure to address the issue explicitly again reflects badly on
  546.      its designers' grasp of intercomputer networking issues.
  547.      (Another possibility is that the whole H-FP notion stems from the
  548.      use of X.25 as a Host-Host
  549.  
  550.      ________________
  551.      *  That is, as a distributed processing mechanism which allows
  552.         Host operating systems to be relieved of the burden of
  553.         interpreting higher level protocols "inboard" of themselves by
  554.         virtue of allowing Host processes to manipulate "outboard"
  555.         interpreters of the protocols on their behalf.  Note that the
  556.         outboarding may be to a separate Front-End processor or to the
  557.         CSNP itself.  (The latter is likely to be found in
  558.         microprocessor-based LAN "BIU's.")  Note also that when
  559.         dealing with "process-level" protocols (ARM L III;
  560.         approximately ISORM L5-7), only part of the functionality is
  561.         outboarded (e.g., there must be some Host-resident code to
  562.         interface with the native File System for a File Transfer
  563.         Protocol) and even when outboarding Host-Host protocols (ARM L
  564.         II; approximately ISORM L4 plus some of 5) the association of
  565.         logical connections (or "sockets") with processes must be
  566.         performed inboard--which is why, by the way, it's annoying to
  567.         find ISO L5 below ISO L6: because, that is, you'd like to
  568.         outboard "Presentation" functionality but its protocol expects
  569.         to interact with the "Session" protocol, the functionality of
  570.         which can't be outboarded.  (Although this approach, not the
  571.         proper context for a full treatment of the H-FP approach, it
  572.         is also of interest that the approach can effectively insulate
  573.         the Host from changes in the protocol suite, which can be a
  574.         major advantage in some environments.)
  575.  
  576.  
  577.  
  578.  
  579.                                      8
  580.      RFC 874                                            September 1982
  581.  
  582.  
  583.      protocol so that some might think of it in its Host aspect as
  584.      "simply" a way of getting at the H-HP.  This interpretation does
  585.      give rise to the interesting observation that DCE's seem to need
  586.      a protocol as strong as TCP amongst themselves, but doesn't
  587.      strike the author as particularly convincing evidence for viewing
  588.      X.25 as anything like a proper H-FP--if for no other reason than
  589.      that a central premise of Outboard Processing is that the
  590.      Host-side H-FP module must be compact relative to an inboard
  591.      generic Network Control Program.)
  592.  
  593.           X.25, then, is rather schizophrenic:  It exceeds its brief
  594.      as an  interface protocol by pretending to be end-to-end
  595.      (Host-Host) in some respects; it is by no means a full end-to-end
  596.      protocol (its spec very properly insists on that point on several
  597.      occasions); it's at once too full and too shallow to be a good
  598.      interface; and it's poorly structured to be treated as if it were
  599.      "just" an H-FP.  (Some would phrase the foregoing as "It's
  600.      extremely ill layered"; we wouldn't argue.)
  601.  
  602.      A Note on "Gateways"*
  603.  
  604.           Although it was at least implied in the discussion of
  605.      conceptual model problems, one aspect of X.25/X.75 internetting
  606.      is sufficiently significant to deserve a section of its own:  Not
  607.      only does the link-by-link approach taken by CCITT make it
  608.      unlikely that alternate routing can take place, but it is also
  609.      the case that ARPANET Internet Protocol (IP) based internetting
  610.      not only permits alternate routing but also could alt-route over
  611.      an "X.25 Subnet."  That is, in IP's conceptual model, Gateways
  612.      attach to two or more comm subnets "as if they (the Gateways)
  613.      were Hosts."  This means that they interpret the appropriate
  614.      Host-comm subnet processor protocol of whatever comm subnets
  615.      they're attached to, giving as the "proximate net address" of a
  616.      given transmission either the ultimate (internet addressed)
  617.      destination or the address of another Gateway "in the right
  618.      direction."  And an implementation of IP can certainly employ an
  619.      implementation of ("DTE") X.25 to get a proximate net, so ... at
  620.      least "in an emergency" X.25 interface presenting Public Data
  621.      Networks can indeed carry IP traffic.  (Note also that only the
  622.      proximate net's header has to be readable by the nodal processor
  623.      of/on the proximate net, so if some appropriate steps were taken
  624.      to render the data portion of such transmissions unintelligible
  625.      to the nodal processors, so much the better.)
  626.  
  627.      ________________
  628.      *  This section was added to address the ill-founded concerns of
  629.         several ISORMites that "TCP/IP won't let you use Public Data
  630.         Nets in emergencies."
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.                                      9
  639.      RFC 874                                            September 1982
  640.  
  641.  
  642.           (Further evidence that X.75 internetting is undesirable is
  643.      found in the fact that the U.S. National Bureau of Standards has,
  644.      despite its nominal adoption of the ISORM, inserted IP at
  645.      approximately L3.5 in its version of the Reference Model.)
  646.  
  647.      The Off-Blue Blanket
  648.  
  649.           Although touched on earlier, and not treatable at much
  650.      length in the present context, the topic of security deserves
  651.      separate mention.  We are familiar with one reference in the open
  652.      literature [1] which appears to make a rather striking point
  653.      about the utility of X.25 in a secure network.   Dr. Kent's point
  654.      that the very field sizes of X.25 are not acceptable from the
  655.      point of view of encryption devices would, if correct (and we are
  656.      neither competent to assess that, nor in a position to even if we
  657.      were), almost disqualify X.25 a priori for use in many arenas.
  658.      Clearly, uncertified "DCE's" cannot be permitted to read
  659.      classified (or even "private") data and so must be "encrypted
  660.      around," after all.
  661.  
  662.           It would probably be the case, if we understand Dr. Kent's
  663.      point, that X.25 could be changed appropriately--if its
  664.      specifiers were willing to go along.  But this is only one
  665.      problem out of a potentially large number of problems, and,
  666.      returning briefly to our concern with the interplay of X.25 and
  667.      the DoD, those persons in the DoD who know best what the problems
  668.      are and/or could be are debarred from discussing them with the
  669.      specifiers of X.25.  Perhaps a sufficiently zealous ISORM
  670.      advocate would be willing to suggest that Professor Kuo's
  671.      publisher be subsidized to come out with a new edition whenever a
  672.      problem arises so that if Dr. Kent happens to spot it advantage
  673.      can continue to be taken of his ability to write for the open
  674.      literature--but we certainly hope and trust that no ISORMite
  675.      would be so tone-deaf as to fail to recognize the facetiousness
  676.      of that suggestion.
  677.  
  678.           In short, it appears to be difficult to dispute the
  679.      assertion that whatever sort of security blanket X.25 could
  680.      represent would at best be an off shade of blue.
  681.  
  682.      Space-Time Considerations
  683.  
  684.           Another topic touched on earlier which deserves separate
  685.      mention, if only to collect the scattered data in a single
  686.      section, is that of what have been called space-time
  687.      considerations.  That is, we are concerned about how well X.25 in
  688.      particular and the ISORM-derived protocols in general will
  689.      implement, both in terms of size of protocol interpreters (PI's)
  690.      and in terms of execution and delay times.
  691.  
  692.  
  693.  
  694.  
  695.  
  696.  
  697.                                     10
  698.      RFC 874                                            September 1982
  699.  
  700.  
  701.           On the space heading, certainly the fact that X.25 offers
  702.      more functionality in its end-to-end guise than is required to
  703.      fulfill its network interface role suggests that X.25 PI's will
  704.      be bigger than they need be.  As an aside--but a striking one--it
  705.      should be noted that X.25's end-to-end functions are at variance
  706.      with the ISORM itself, for the "peer entity" of a DTE X.25 entity
  707.      must surely be the local DCE X.25.  Perhaps a later version of
  708.      the ISORM will introduce the polypeer and give rise to a whole
  709.      new round of Layering-Theologic controversy.*  Speaking of the
  710.      ISORM itself, those who hold that each layer must be traversed on
  711.      each transmission are implicitly requiring that space (and time)
  712.      be expended in the Session and Presentation Levels even for
  713.      applications that have no need of their services.  The Well-Known
  714.      Socket concept of the ARM's primary Host-Host protocol, the
  715.      Transmission Control Protocol (TCP), lets Session functionality
  716.      be avoided for many applications, on the other hand--unless ISORM
  717.      L5 is to usurp the Host's user identification/authentication role
  718.      at some point.  (Yes, we've heard the rumors that "null layers"
  719.      might be introduced into the ISORM; no, we don't want to get into
  720.      the theology of that either.)
  721.  
  722.           On the time heading, X.25's virtual circuit view can be
  723.      debilitating--or even crippling--to applications such as
  724.      Packetized Speech where prompt delivery is preferred over ordered
  725.      or even reliable delivery.  (Some hold that the X.25 datagram
  726.      option will remedy that; others hold that it's not "really
  727.      datagrams"; we note the concern, agree with the others, and pass
  728.      on.)  Speaking of reliable delivery, as noted earlier some
  729.      observers hold that in order to present an acceptable virtual
  730.      circuit X.25 must have a protocol as strong as TCP "beneath"
  731.      itself; again, we're in sympathy with them.  Shifting focus again
  732.      to the ISORM itself, it must be noted that the principle that
  733.      "N-entities" must communicate with one another even in the same
  734.      Host via "N-1 entities" even in the same Host is an over-zealous
  735.      application of the Principle of Layering that must consume more
  736.      time in the interpreting of the N-1 protocol than would a direct
  737.      interface between N-level PI's or such process-level protocols as
  738.      FTP and Telnet, as is done in the ARPANET-derived model.
  739.  
  740.           Other space-time deficiencies could be adduced, but perhaps
  741.      a shortcut will suffice.  There is a Law of Programming
  742.      (attributed to Sutherland) to the effect that "Programs are like
  743.      waffles: you should always throw the first one out."  Its
  744.      relevance should become
  745.  
  746.      ________________
  747.      *  And perhaps we now know why some just draw the highrises.
  748.  
  749.  
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756.                                     11
  757.      RFC 874                                            September 1982
  758.  
  759.  
  760.      clear when it is realized that (with the possible exception of
  761.      X.25) ISORM PI's are in general either first implementations or
  762.      not even implemented yet (thus, the batter, as it were, is still
  763.      being mixed).  Contrast this with the iterations the
  764.      ARPANET-derived PI's--and, for that matter, protocols--have gone
  765.      through over the years and the grounds for our concern over
  766.      X.25/ISORM space-time inefficiency become clear irrespective of
  767.      corroborative detail. Factor in the consideration that space-time
  768.      efficiency may be viewed as contrary to the corporate interests
  769.      of the progenitors of X.25 ("the PTT's") and at least the current
  770.      favorite for ISORM Level 4 (ECMA--the European Computer
  771.      Manufacturers' Association), and it should become clear why we
  772.      insist that space-time considerations be given separate mention
  773.      even though touched upon elsewhere.*
  774.  
  775.      Getting Physical
  776.  
  777.           Still another area of concern over X.25 is that it dictates
  778.      only one means of attaching a "DTE" to a "DCE."  That is, earlier
  779.      references to "the X.25 protocol(s)" were not typographical
  780.      errors. Most of the time, "X.25" refers to ISORM Level 3;
  781.      actually, though, the term subsumes L2 and L1 as well.  Indeed,
  782.      the lowest levels constitute particular bit serial interfaces.
  783.      This is all very well for interfacing to "Public Data Nets"
  784.      (again, it must be recalled that X.25's roots are in CCITT), but
  785.      is scarcely appropriate to environments where the communications
  786.      subnetwork may consist of geosynchronous communications satellite
  787.      channels, "Packet Radios," or whatever.  Indeed, even for
  788.      conventional Local Area Networks it is often the case that a
  789.      Direct Memory Access arrangement is desired so as to avoid
  790.      bottlenecking--but DMA isn't HDLC, and the "vendor supported X.25
  791.      interface" so prized by some won't be DMA either, one imagines.
  792.      (Speaking of LAN's, at least the evolving standard in that
  793.      arena--"IEEE 802"--apparently will offer multiple physical
  794.      interfaces depending on comm subnet style [although there is some
  795.      disagreement on this point amongst readers of their draft specs];
  796.      we understand, however, that their Level 2 shares X.25's end-end
  797.      aspirations--and we haven't checked up on DMA capability.)  X.25,
  798.      then, imposes constraints upon its users with regard to interface
  799.      technology that are inappropriate.
  800.  
  801.      ________________
  802.      *  The broad issue of design team composition is amplified in
  803.         Padlipsky, M. A., "The Illusion of Vendor Support", M82-49,
  804.         The MITRE Corporation, September 1982.
  805.  
  806.  
  807.  
  808.  
  809.  
  810.  
  811.  
  812.  
  813.  
  814.  
  815.                                     12
  816.      RFC 874                                            September 1982
  817.  
  818.  
  819.      Other Observers' Concerns
  820.  
  821.           This paper owes much to conversations with a number of
  822.      people, although the interpretations of their concerns are the
  823.      author's responsibility.  Mention should be made, however, of a
  824.      few recent documents in the area:  The Defense Communications
  825.      Agency (DCA Code J110) has sent a coordinated DoD position [2] to
  826.      NBS holding that X.25 cannot be the DoD's sole network interface
  827.      standard; Dr. Vinton Cerf of the ARPA Information Processing
  828.      Technology Office made a contribution to the former which
  829.      contains a particularly lucid exposition of the desirability of
  830.      proper "datagram" capability in DoD comm subnets [3]; Mr. Ray
  831.      McFarland of the DoD Computer Security Evaluation Center has also
  832.      explored the limitations of X.25 [4]. Whether because these
  833.      authors are inherently more tactful than the present author, or
  834.      whether their positions are more constraining, or even whether
  835.      they have been more insulated from and hence less provoked by
  836.      uninformed ISORMite zealots, none has seen fit to address the
  837.      "quality" of X.25.  That this paper chooses to do so may be
  838.      attributed to any one of a number of reasons, but the author
  839.      believes the key reason is contained in the following:
  840.  
  841.      Conclusion
  842.  
  843.           X.25 is not a good thing.
  844.  
  845.      References
  846.  
  847.      [1] Kent, S. T., "Security in Computer Networks," in Kuo, F.,
  848.          Ed., Protocols and Techniques for Data Communications
  849.          Networks, Prentice-Hall, 1981, pp. 369-432.
  850.  
  851.      [2] Letter to NBS from P. S. Selvaggi, Chief, Interoperability
  852.          and Standards Office, 7 April 1982.
  853.  
  854.      [3] Cerf, V. G., "Draft DoD Position Regarding X.25" in undated
  855.          letter to P. S. Selvaggi.
  856.  
  857.      [4] Personal communications.
  858.  
  859.      
  860.  
  861.  
  862.  
  863.  
  864.  
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.                                     13